1. Field of the Invention
This invention relates to methods and systems to notify system users and/or applications of changes to the state of a computer system and/or to the data residing within the system. More particularly, the present invention relates to computer-implemented methods and systems to notify database users and/or applications of events within the database data or to the database system itself.
2. Description of the Related Art
Databases typically constitute the entire repository of information in an enterprise. As such, databases have become an integral and vital part of corporate infrastructure, storing data relating to virtually every aspect of a company's logical and physical structure, including organization, human resources, product lines, customers and financial information, for example. Such a database may be accessed by a variety of entities (including the database administrator, the company's employees, outside suppliers and/or computer programs both within and without the company), each such entity typically retrieving different data and information therefrom. Users and/or programs that must access the database often have an interest in events within the computerized database system itself (hereafter, “system events”) or in the data that is resident in the database system (hereafter, “data events”). An event, within the context of the present invention, denotes a significant change of some sort. The change may be in the system state or configuration or in any other parameter of interest. Users of systems are typically interested in knowing about and acting on any changes of significance that takes places in the system that might potentially affect them.
For example, users and/or programs accessing the database may want to be notified upon the occurrence of specified systems events, such as whether the database is about to shutdown or startup, is running out of disk space or rollback segments or upon the occurrence of logons and logoffs, for example. Likewise, inventory managers, for example may want to be notified upon the occurrence of specified data events, such as when the inventory for a specific part falls below a critical threshold, so that additional parts can be ordered in a timely manner. In each case, some action may be taken based upon such system- or data-related information extracted or otherwise obtained from the database.
The extraction of such information from a database may be carried out, for example, by carrying out the steps outlined in FIGS. 1a or 1b. As shown in FIG. 1a, the interested user may query the database (step S1a) and may take some action based upon the database query result (step S2a). For example, the database query may include a number of Structured Query Language (SQL) or Procedural Language/Structure Query Language (PL/SQL) statements that may ascertain the status of one or more tables within the database. This sequence may then be repeated, for example, until the database query reveals that the event of interest has occurred. Such a repetitive cycle, however, is believed to be inefficient, wasteful and time consuming. Another method of obtaining information relative to events of interest within a database is shown in FIG. 1b. To notify a user of the occurrence of an event, a trigger may be declared, as shown in step S1b. A trigger is a procedure that is implicitly executed when, for example, certain Data Manipulation Language (DML) statements (such as INSERT, UPDATE or DELETE, for example) are issued against an associated table in the database, as disclosed, for example, in Chapter 17 of Oracle8 Server Concepts, release 8.0 {circle around (C)} 1997 Oracle Corporation (or later versions thereof), which publication is incorporated herein by reference in its entirety. The trigger, as shown at step S2b, may include logic, such as SQL or PL/SQL statements that are executed when one of the aforementioned statements are issued against the table or tables of interest. Thereafter, another application may check a trigger flag (step S3b) that is updated by the trigger declared in step S1b and a still further application may take appropriate action based upon the state of the trigger flag, as shown at step S4b. Again, the user is not notified that the event of interest occurred until some outward manifestation of the event is apparent of until a check of the trigger flag reveals that the state thereof has changed. The user may have to repeatedly check the state of the trigger flag to ascertain whether is has changed state. This cyclic polling process is also believed to be inherently inefficient, wasteful of database resources and time consuming. Such a database request—reply synchronous process forces the user to “pull” the specific information of interest from the database by issuing a request therefor, even through the events of interest most often occur asynchronously. FIGS. 1a and 1b assume that the user (whether system administrator, database user or application) is tightly integrated with the database. For example, the user in the examples of FIGS. 1a and 1b may be required to log onto the database to query the database and/or to code the appropriate trigger.
FIG. 2 shows another paradigm in database event notification. Indeed, FIG. 2 shows an example of retrieving information from a database wherein the database “pushes” information from the database to a number of loosely coupled users. As depicted therein, the contents of a database 210 (or a selected portion thereof) are pushed or broadcast (as symbolized by the broadcast antenna tower 220), to the Internet 230 and/or across another communications channel. A number of clients, such as shown at 245, 255 and 265 filter the pushed database contents through corresponding client-side filters 240, 250 and 260 coupled between the Internet 230 and the clients 245, 255 and 265. Assuming, for example, that the database 210 is or includes a repository of news information, a large amount of information may be continually and indiscriminately pushed or broadcast through the Internet 230 to clients 245, 255 and 265 using the service. However, client 245 may only be interested in receiving a small portion of the pushed news information. For example, client 245 may only be interested in basketball information. More specifically, client 245 may one be interested in information directly relating to the Boston Celtics, for example. In that case, the client-side filter 240 may be caused to filter out any information relating to the Boston Celtics (using specified keywords, for example) from the stream of information pushed by database 210, to deliver only Celtics news to the client 245. Similarly, client 255 might be running an automated stock trading program, configured to purchase a specific stock (e.g. XYZ Corp.) when a predetermined combination of market conditions exist (e.g., when XYZ trades for under $20 and ABC Corp. trades for over $55). However, the system 200 of FIG. 2 is not equipped to selectively push data relating only to the share price of XYZ and ABC corporations directly to client 265, but only to aim a great flow of information, fire hose-like, toward the clients 245, 255 and 265. In effect, the client 265 is inundated with a great deal of information of which it has no interest and may have to receive the entire stock ticker in order to extract therefrom the information of interest. Such a flood of unwanted information needlessly consumes bandwidth and may clog corporate Intranets. This problem is exacerbated by the fact that the database 210 typically pushes it information out at regular intervals, irrespective of whether the information of interest to the clients 245, 255 or 265 has been updated since the last push, thereby often pushing duplicative and extraneous information onto the Internet and ultimately to the clients 245, 255 or 265. Because of its inherent limitations, the paradigm of FIG. 2 has largely been abandoned, although no suitable alternative is believed to have emerged in its stead.
What are needed, therefore, are methods and systems to notify users of database systems of interesting changes to the database system or data that is efficient and economical in terms of bandwidth, time and effort. In particular, what are needed are methods and systems allowing the detection of system and data events, as well as the publication and delivery of notifications thereof only to those clients having expressed an interest therein. Moreover, what are needed are methods and systems that deliver only those notifications of specific interest to each client. Such methods and systems, optimally, should asynchronously publish and deliver the notifications of systems and data events of interest to the clients, the publication and delivery thereby closely matching the manner in which the events occur and are detected.